Method for the transmission of user data objects according to a profile information object

ABSTRACT

Disclosed is a method for transmitting user data objects from a data-supplying component or a data server to a telecommunication device of a user via a connection component. The data-supplying component is informed via profile information in a profile object what types of user data objects the connection component or the telecommunication unit is able to process on its own such that the data supplying component can specifically transmit user data objects to the telecommunication device, which belong to the type that the telecommunication device can process. Hence, the data-supplying component is prevented from sending user data objects of a type that has to be converted by the connection component on the transmission path in order to be able to processed by the telecommunication device.

BACKGROUND OF THE INVENTION

The present invention relates to a method for the transmission of userdata objects from a data supply component or a data server to atelecommunication device of a user via a connection component, withprofile information in a profile object of the data supply componentindicating which type of user data objects the connection component orthe telecommunication device is able to process on its own.

A method for the transmission or downloading of user data objects from adata supply component onto a telecommunication device, particularlydesigned as a mobile radio device, is currently being discussed. Thestarting point for such discussions is that the telecommunication deviceis located in a telecommunication network designed as a mobile radionetwork, in which data generally, and user data objects in particularly,are transmitted via a protocol specified by the WAP Forum (WAP: WirelessApplication Protocol). It is further assumed that the data supplycomponent of a data or content supplier is located in a furthertelecommunication network which is particularly embodied as an InternetProtocol-based network. To establish a data connection between the datasupply component and the telecommunication device at least two differentsub-interfaces are needed; namely an air interface on the one hand and acable-based interface on the other. There is provision for WAP protocolsto be used, as already mentioned, for bridging the air interface. Bycontrast, in the telecommunication network of the data supply component,HTTP (HTTP: Hypertext Transfer Protocol) is used. Thus, since differentprotocols are used on the air interface and the network side, there isprovision for a connection component to be used (in this instance, whatis known as a WAP gateway) which adapts the user data to the variouslower layers (air interface, e.g., WSP (Wireless Session Protocol) as aWAP; network side: HTTP). This type of WAP gateway also is generallycapable of converting data types or formats (e.g., translating the fileformat “gif” into “for files of type image or still image).

Telecommunication devices such as mobile radio devices or mobile phonesgenerally differ from each other in their characteristic features orcapabilities. Thus, for example, the characteristics of the displaydevices differ greatly in some cases (e.g., in size and resolution) andthereby also their capabilities to be able to display or processspecific file types or file formats. So that a data supply component ora data supply server in a network can obtain knowledge about thecharacteristics or capabilities of a WAP-capable telecommunicationdevice of a user, the WAP Forum has standardized what is known as theUA-Prof (UA-Prof: User Agent Profile), with the aid of which thecharacteristics of a WAP-capable telecommunication device can be madeknown on the network side (i.e., in the network of the data supplycomponent). The method also takes into account the capabilities of a WAPgateway which handles the data transferred between telecommunicationdevice and data supply component and can also modify such data. On thenetwork side, the provision of suitable data by a server also results inthe characteristics of the WAP gateway being relevant.

A description is given below, with reference to FIG. 1, for a generalcase of how a data supply component D receives the current UA-Prof of aWAP-capable telecommunication device T. Initially, upon registration ofthe WAP-capable telecommunication device T or the setting up of a WSPconnection, what is known as a basic profile BP or basic profileinformation is transferred to the WAP gateway G. If the characteristicsor capabilities of the telecommunication device T have been changed orexpanded by an additionally-connected line component, such as anadditional hardware component (e.g., color display), an additionaldifference profile DP1 or first difference profile information is sentwith the basic profile as a first sub-profile information object to theWAP gateway G, as is depicted by step 1 (“1” in the circle). Bothprofiles, namely BP and DP1, if necessary, can be buffered and evaluatedby WAP gateway G; cf., step 2. WAP gateway G can now for its partsupplement the received profiles BP and DP1 by a separate differenceprofile DP2 or second difference profile information. This isadvantageous when the WAP gateway G has particular characteristics orcapabilities which differ from those of the BP and DP1 profiles sentbeforehand by the WAP-capable telecommunication device T or whichsupplement these profiles. All three profiles are then transmitted instep 3 as a second sub-profile information object to the data supplycomponent D. The data supply component D creates on the basis of alltransferred profiles (BP, DP1 and DP2) a resulting overall profile oroverall profile object RP for the WAP-capable telecommunication deviceT, as indicated by step 4. The resulting profile RP, containing theindividual characteristics of the WAP-capable telecommunication device Tand the supplementary capabilities of the WAP gateway G and possibly ofother network units, is the current UA-Prof and will be administered bythe data supply component D.

During a WSP session the downloading of any data, particularly user dataobjects, can be initiated by a WAP-capable telecommunication device T bysending a data request message. Should the characteristics orcapabilities of the WAP-capable telecommunication device have changed inthe interim (i.e., after a WSP connection was first established), suchas through connection of another additional hardware component, in ortogether with a data request message issued, a current adapteddifference profile DP3 or a third difference profile information aretransmitted in a first sub-profile information object to the WAP gatewayG in step 5 and, if necessary, evaluated there according to step 6. Theremaining transmission of the basic profile BP and the differenceprofiles DP3 and DP2 in a second sub-profile information object betweenWAP gateway G and data supply component D in accordance with step 7 andthe creation of the resulting profile in accordance with step 8 areundertaken in a similar way to the method described above. If thecharacteristics or capabilities of the WAP-capable telecommunicationdevice have not changed after the first setup of the WSP connection, fora data request message issued, the method refers back to the profilepreviously transferred and buffered in WAP gateway G (cf. step 2) or atthe data supply component (cf., step 4).

The principle for generating the resulting profile is fairlysophisticated, the resulting profile or overall profile being generatedfrom the basic profile and any number of difference profiles.

The basic assumption is further made for the use and definition of theUA-Prof that a WAP gateway recognizes and suitably handles the datatypes transmitted to the WAP-capable telecommunication device; i.e.,changes or converts them if necessary on the path from the data supplycomponent to the telecommunication device. A typical example of this isthe conversion of an image. Assuming that the telecommunication devicecan only display images of the “jpeg” type or format and that the datasupply component transmits a “gif”-type image, the WAP gateway canconvert the image in accordance with its capabilities from type “gif” totype or format “jpeg” and pass the converted image on to thetelecommunication device on which it can then be processed or displayed.

This method is, accordingly, supported by UA-Profs, in that theWAP-capable telecommunication device initially specifies in its basicprofile BP the ability to process or display images of type “jpeg.” TheWAP gateway detects this specification, knows that it is capable itselfof converting images of type “gif” into type “jpeg” and thereforespecifies in difference profile DP2 that images of type “gif” also willbe supported. On the data supply component side the resulting overallprofile RP is generated. The data supply component, however, now nolonger can distinguish between the original capabilities of thetelecommunication device and the additional capabilities of the overallsystem of WAP-capable telecommunication device and WAP gateway. In thisexample, the server-side transmission (i.e., transmission on the datasupply component side) of an image of type “gif” is now possible, withthe gateway undertaking the corresponding conversion.

Problems may arise however, when the file types requiring conversion bythe WAP gateway are enclosed (packed) into another data format whichcannot be suitably handled by the WAP gateway. There are two mainexamples which illustrate this situation:

1. Digital Rights Management (DRM): The solution currently specified inthe WAP Forum for managing rights of protected digital objects is basedon the fact that the object is transported in a container file or in acontainer, which, for unencrypted objects is of type“application/vnd.wap.drm.message” and for encrypted objects is of type“application/vnd.wap.drm.content.” With unencrypted objects there istheoretically the option for a WAP gateway to access the enclosed objectand to change it, but there is no explicit provision for this to bedone. With encrypted objects the WAP gateway has no possibility ofaccessing the object since it does not have the key and the data,therefore, only appears as a binary packet. Even when the enclosedobject is an image of the type known to the WAP gateway which,accordingly, could be converted into another type, this is not possiblein the case described. The enclosed object would be passed on unchangedby the WAP gateway to the telecommunication device on which it would notbe able to be displayed.

2. Multimedia Messaging Service (MMS): In the MMS the message istransmitted in the form of a Multimedia Message (MM) from a so-calledMMS-Relay/Server (which serves as an MMS switching unit in a network) toan MMS Client, a specific application on the WAP-capabletelecommunication device. In the solution specified by the WAP Forum theMM is a message with binary codes for presentation of the header fieldswhich are not known to the WAP gateway. The messages are of type“application/vnd.wap.mms-message” and contain the objects to betransferred. The WAP gateway, in its turn, has the opportunity ofextracting the objects from the message and adapting them to thefeatures of the receiving telecommunication device. If an object of aspecific type, requiring conversion by the WAP gateway, is integratedinto the MMS message by the MMS Relay Server, the WAP gateway cannotperform its task, wherein the object arrives at the telecommunicationdevice unchanged and cannot be used there. Furthermore, the fact thatformation of an overall profile, as has been described above, makes itno longer possible to distinguish between how the integral components ofthe characteristics of the telecommunication device (possibly withadditional hardware components) and the additional characteristics ofthe system made up of telecommunication device and WAP gateway also mayhave a negative effect if, for example, an object can be offered indifferent formats by the data supply component, of which some require aconversion by the WAP gateway to enable them to be processed by thetelecommunication device, and others can be forwarded unchanged from theWAP gateway to the telecommunication device. Here, the server-side(i.e., from the data supply component) selection of a format whichrequires no conversion by the WAP gateway is advantageous since aconversion can lower the quality of the object, additional time isneeded for downloading the object for conversion, computing power isrequired in the WAP gateway and the user can incur additional costs,depending on the billing model.

The present invention seeks to improve a method such as has beendescribed with reference to FIG. 1, for example, such that a moreefficient transmission of user data objects, particularly of encryptedor packed user data objects, is made possible.

SUMMARY OF THE INVENTION

For a method for the transmission of user data objects, a data supplycomponent to supply user data objects is provided which transmitsinformation objects over at least one connection component to atelecommunication device of a user in accordance with an overall profileinformation object. The overall profile information object specifies inthis case which type of a user data object can be transmitted to thetelecommunication device so that it can process the object. In addition,a first item of profile information is inserted into the overall profileinformation object which specifies which type of user data object can bedirectly processed by the telecommunication device. Furthermore a seconditem of profile information can be inserted which specifies which typeof user data object can be converted by the connection component into atype of user data object which can be processed by a telecommunicationdevice. This profile information, particularly the first profileinformation, thus allows the data supply component where possible toselect the types of user data object for a transmission to thetelecommunication device which can be directly processed by thetelecommunication device and do not require any manipulation orconversion on the part of the connection component to enable them to beprocessed by the telecommunication device.

Consequently, in accordance with an advantageous embodiment, user dataobjects of a type in accordance with the first profile information aretransmitted from the data supply component to the telecommunicationdevice initially with high priority. As such, a check is made as towhether the data supply component is supplying user data objects able tobe processed directly by the telecommunication device. If the check issuccessful, these types of user data objects are finally transmitted tothe telecommunication device. Referring to the example given above, inwhich the telecommunication device is able to process image data of type“jpeg,” the connection component is able to convert image data of type“gif” into type “jpeg” and finally the data supply component providesimage data of type “jpeg” and “gif.” The data supply component, since itrecognizes from the first item of profile information that thetelecommunication device can process data of a type “jpeg,” immediatelytransmits this type of image data of type “jpeg” to thetelecommunication device as user data objects. On the one hand thisrequires no conversion of image data by the connection component(possible conversion costs can be saved and the transmission time alsoreduced without conversion) and packing or encryption of user dataobjects is possible since the data supply component only transmits tothe telecommunication device user data objects for which it knows, onthe basis of the first profile information, that the device can processthe user data object.

If the check as to whether the data supply component is supplying userdata objects which can be processed directly by the telecommunicationdevice produces a negative result, then, in accordance with a furtherembodiment of the present invention, user data objects of a type inaccordance with the second profile information are transmitted at alower priority than before from the data supply component to thetelecommunication device.

In accordance with a further advantageous embodiment, thetelecommunication device transmits, before the transmission of user dataobjects from the data supply component to telecommunication device, afirst sub-profile information object with the first profile informationto the connection component, which for its part supplements the firstsub-profile information object by the second profile information to forma second sub-profile information object and transfers this to the datasupply component. There, on the basis of the second sub-profileinformation object or all profile information transferred, an overallresulting profile information object can be created.

It is further possible for the telecommunication device to be expandedby an additional service component which enables it to extend the scopeof the user data objects able to be processed by the telecommunicationdevice. This type of service component can, for example, be anadditional hardware component, such as a specific color display devicewith high resolution for displaying high-resolution and color images orgraphics, and also an additional software component or softwareapplication, such as for processing and playing music data in the MP3format. This type of service component then may be in a position toprocess types of user data objects which the telecommunication devicecan already process, but it also may be in a position to process furthertypes of user data object which the telecommunication device itselfcannot process. As a consequence, the first sub-profile informationobject can be supplemented by a third item of profile information whichspecifies the types of user data object by which the scope of the userdata objects of the telecommunication device is expanded by theadditional service component.

To minimize the volumes of data to be transferred between thetelecommunication device and the connection component (particularly ifan air interface between them is provided) and/or between the connectioncomponent and the data supply component, it is also conceivable, inaccordance with an advantageous embodiment, to provide the profileinformation in the first and/or the second sub-profile informationobject in the form of a reference, which points to profile informationin each case which is stored on the data supply component or on afurther data supply component connected to it. As such, only addresses,for example a URL (URL: Uniform Resource Locator) can be provided in asub-profile information object which reference a storage location in thedata supply component or other data supply components, such as of themanufacturer of the telecommunication device or the additional servicecomponent. The data supply component only has to select the address whencreating the overall profile object in order to obtain the correspondingprofile information and insert it into the overall profile object.

In accordance with a further advantageous embodiment, thetelecommunication device is located in the first telecommunicationnetwork and the data supply component and/or the further data supplycomponent in a second telecommunication network, with the first andsecond telecommunication networks being connected to each other. Theconnection component then may be arranged in the first or secondtelecommunication network or serve to interconnect the twotelecommunication networks. In the case of a number of connectioncomponents, the connection components can be arranged in the locationsjust specified (e.g., as will be explained later, a communicationcomponent can serve as a WAP gateway for connecting the twotelecommunication networks while one or more other communicationcomponents can be provided, for example, as conversion units of data oruser data objects in one of the specified telecommunication networks).In this case, it is possible for the first telecommunication network tobe embodied as a mobile radio network, which is operated in accordancewith the GSM (Global System for Mobile Communications) or the UMTS(Universal Mobile Telecommunications system) Standard. For this type ofembodiment of a first telecommunication network, the user data objectscan be transmitted to the telecommunication device via WAP protocols,particularly the Wireless Session Protocol. In this context, theconnection component can be embodied to connect the first and secondtelecommunication networks as a WAP gateway. It is further conceivablefor the second telecommunication network to be embodied as a networkbased on an Internet protocol in which the data is transferred via ofthe Hypertext Transfer Protocol.

In accordance with an advantageous embodiment, the telecommunicationdevice includes a radio module and is, in particular, embodied as amobile telephone, a cordless telephone, a portable computer or asmartphone (a combination of mobile telephone and small portablecomputer).

In accordance with a further advantageous embodiment, the user dataobjects may contain text information, audio information, videoinformation, executable programs, software modules, or a combination ofthese types of data.

Additional features and advantages of the present invention aredescribed in, and will be apparent from, the following DetailedDescription of the Invention and the Figures.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 shows a block diagram with the components involved in the methodfor transmission of the user data objects, using characteristic profilesor user agent profiles of the different components provided in thetransmission path, including the data flow between the components.

FIG. 2 shows a table for identification or encoding of componentsprovided in the data transmission path into the relevant characteristicprofiles.

FIG. 3 shows a diagram of a characteristic profile in XML (XML:Extensible Markup Language) in accordance with a first embodiment of thepresent invention.

FIG. 4 shows a diagram of a characteristic profile in XML in accordancewith a second embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

Possible embodiments for transmission of user data objects from a datasupply component to a telecommunication device, particularly a mobiletelephone of the user (simply referred to as a terminal below) will nowbe explained.

For the explanation of the preferred embodiments of the invention thestarting point is a corresponding configuration of the telecommunicationarrangement as has already been discussed with reference to FIG. 1. Atelecommunication arrangement of this type again includes a data supplycomponent or a data server D to supply user data objects (be theyencrypted or unencrypted, packed into a container file or not, etc.),aconnection component G for forwarding the data or user data objects andfinally a telecommunication device or terminal T of a user. Again, thestarting point is that the terminal T is located in a firsttelecommunication network embodied as a mobile radio network, in whichthe data in general and particularly user data objects are transmittedvia a protocol specified by the WAP Forum (WAP: Wireless ApplicationProtocol). It is further assumed that the data supply component of adata or content provider is located in a second telecommunicationnetwork which is embodied as a network based on an Internet protocol(such as http). As a connection device to establish a data connectionbetween the first telecommunication network and the secondtelecommunication network the communication component which serves inthe configuration described as what is referred to as a WAP gateway isprovided.

For notifying the characteristics, especially relating to processing ofspecific user data objects to the data supply component D, in accordancewith the method shown in FIG. 1, the characteristics are represented incharacteristic profiles or “UA profiles” (UA: User Agent Profile) whichare advantageously based on the metalanguage XML (XML—Extensible MarkupLanguage). XML-based formats are particularly suitable for platform andsoftware independent exchange of structured data between programs andcomputers or software and hardware components of different manufacturersand systems.

A profile can describe a number of components (e.g., for software,hardware, WAP Push, etc.), where each component can contain a number ofattributes and the associated values (in the hardware components, forexample, possible attributes are screen size, color displaycapabilities, etc.). A basic structure of a profile is shown below, ashas been defined by the WAP Forum for UA-Prof:

Component_(—)1

Attribute 1a=Value 1a

Attribute 1b=Value 1b

Component_(—)2

Attribute 2a=Value 2a

Attribute 2b=Value 2b

Attribute 2c=Value 2c

Attribute 2d=Value 2d

This type of sub-division has a number of advantages. All components andattributes can be used flexibly, the structure can be expanded asrequired and allows easy-to-understand presentation options.

A method in accordance with a preferred embodiment of the presentinvention now makes it possible on the server side, that is on the partof the data supply component, for a distinction to be made between thecharacteristics of the WAP-capable terminal here and the additionalcharacteristics of the combination of the WAP-capable terminal andfurther components present in the data transmission network such as theconnection component (simply referred to below as WAP gateways). Usingthe method shown in FIG. 1 as a starting point, the individual profilesor UA profiles (basic profile and a difference profile) are identifiedas to their origin, which allows an evaluation on the server side as towhich conversion functionality of the WAP gateway or of a possibleadditional conversion server, present, for example in the secondtelecommunication network, can be used in the transmission or assignmentof content (as regards user data objects) in a specific format and whichcannot.

There are different options for identifying the reference of a profileof a UA-Prof:

a) In one of the simplest variants the identifier only distinguishesbetween “terminal” and “intermediate entity” (such as WAP gateways). Tothis end, the profile can be provided with simple markings, with themarking of the profile type also being sufficient; e.g., the marking ofthe profile of intermediate entities (WAP gateways, conversion servers,etc.). An advantage of this variant is that changes are not absolutelyrequired on the terminal side nor at the air interface.

b) In a somewhat more complex variant each terminal or each component inthe transmission path provides a separate profile with an individual,previously-agreed code (textual or binary). For example binary code “2”refers to“this profile originates from a WAP gateway.” A greatercertainty compared to variant a) as to the source from which a profileoriginates is advantageous since each profile is to be identified here.In addition, further differentiation can be obtained if, instead of asimple marking (Boolean expression), a larger set of values is used,enabling the categories “WAP-capable terminal,” “WAP gateway,” “WAPproxy” (as a further component in the transmission path) and furthercomponents to be distinguished.

c) This variant builds on variant b) but also contains the informationabout whether further (difference) profiles may be transmitted bysubsequent units or components in the transmission path. For specificapplications it thus becomes possible to suppress the signaling ofconversion options by the WAP gateway and other subsequent conversionunits.

The application of a method in accordance with an embodiment of thepresent invention, for example on loading DRM (DRM: Digital RightsManagement) protected objects and also for MMS (MMS: Multi MediaMessaging Service) has an advantage that the data supply component orthe data supply server can look at the characteristics of theWAP-capable terminal alone and only send the objects or user dataobjects suitable for it. Unsuitable objects are recognized directly bythe data supply component and not transmitted, so the user is not sentunusable objects by mistake.

If the data supply component is able to supply user data objects withthe same content but different data types, an identification ofcharacteristics in UA profiles, that is an assignment of characteristicsto a specific component in the transmission path, has the effect thatthe data supply component always selects for transmission with higherpriority a user data object which can be used on the terminal sidewithout conversion by an intermediate component in the transmission pathsuch as the WAP gateway. Unnecessary data format conversions are thusavoided.

To reiterate, in accordance with the embodiment presented, profiles and(after merging of profiles) profile components are identified inaccordance with their origin and the server side distinction which thismakes possible between characteristics of the WAP-capable terminal andadditional characteristics of the overall system consisting ofWAP-capable terminal, WAP gateway and possibly further components on thetransmission path which can change the content to be transmitted. Withthe identification of the individual profiles or UA-Profs, the followingquestions can be resolved on a server side concerning the transmissionunit (WAP-capable terminal, WAP gateway, intermediate conversion unit,etc.) from which the corresponding profile originates. The server at theend of the transmission chain is intended to take this additionalinformation into account in selecting between different available filetypes and formats. In addition, a unit has the opportunity ofsuppressing further appending of difference profiles if necessary.

At this point it should be pointed out once again that the methoddescribed herein is not restricted to the embodiments given as exampleshere, but can also be applied to other WAP-based applications.

The advantages of the principles depicted above with regard to a methodfor transmission of user data objects using profiles or UA-Profs,especially in connection with the delivery of protected objects, thedelivery of multimedia messages in the Multimedia Messaging Service andfor browsing on the basis of the protocols specified in the WAP Forumnow will be presented in detail.

In accordance with the following example, it is assumed that aWAP-capable terminal which cannot display still images is, however,expanded by a plug-in hardware module to provide this function so thatit can also display still images in the “jpeg” format. As alreadyexplained above, the terminal is connected to the Internet via a WAPgateway which is further able to convert still images from the “gif”format into the “jpeg” format. The difference between the methoddescribed here and the method described at the beginning with referenceto FIG. 1 now lies in the fact that the profiles can be identified asregards their origin. As such, in addition to the capabilities of thecorresponding terminals or transmission units, the information about theterminal or the transmission unit such as the WAP gateway from which therelevant difference profile originates is included. These expandedprofiles are indicated below by an asterisk. Otherwise, the transmissionand processing of the relevant profiles proceeds as already describedwith reference to FIG. 1 which is why, for the explanation of theindividual steps regarding the profiles expanded by an asterisk in thefollowing text, reference is made to the explanation of the profilewithout the asterisk.

Referring to FIG. 1, the WAP-capable terminal T, as well as its basicprofile BP*, also transmits the difference profile DP3* (cf., step 5),which describes the additional capabilities provided by the a hardwaremodule plugged in at the WAP gateway G. As well as the two profiles ofthe WAP-capable terminal (basic profile BP* and difference profileDP3*), this also sends its own difference profile DP2* to the datasupply component D (like the scenario depicted in FIG. 1).

As such, the last element in the transmission chain or the transmissionpath (here, the data supply component D) has knowledge when determiningthe resulting profile RP* (corresponding to the overall profile) aboutwhich capabilities the WAP-capable terminal (expanded with the module)possesses (namely, the display of still images in the “jpeg” dataformat), and which capabilities are to be assigned to an intermediatetransmission unit (namely, the conversion of still images in the “gif”data format into the “jpeg” data format by the WAP gateway). Thesemantics of the identification will be examined below. Of the variantsdescribed above for identifying the profiles, variant c) will be usedbelow, in which, on the one hand, the function of the unit described inthe profile (WAP-capable terminal, WAP gateway, etc.) will be identifiedand, on the other hand, there will be an indication of whether furtherprofiles of subsequent units of the transmission chain may be added.

FIG. 2 shows a table in accordance with an advantageous embodiment of abinary encoding for identification of profiles. In accordance with thistable, a WAP-capable terminal can send its basic profile either with thebinary identifier “−1” or “0” and thereby allow or prevent the othertransmission units in the transmission chain from transmitting theirdifference profiles. The next element in the transmission chain(WAP-capable terminal with add-on module, WAP gateway, possibly WAPproxy or conversion server, etc) which would like to a supplement adifference profile, first evaluates the basic profile of the WAP-capableterminal. If supplementing of difference profiles is allowed, it can nowtransfer its own difference profile with a corresponding identificationin accordance with the table shown in FIG. 2. In this way it would bepossible for the last element in the transmission chain (i.e., theserver) to distinguish between the various (difference) profiles.

Independently of this, each terminal or each transmission unitadditionally may sequentially number its profile. In this case, the datasupply component D would even receive information about the sequence ofthe network elements involved in the transmission of the data.

The syntax of the identification will be examined below. Differentoptions for identifying a profile will be examined quite generally. Theexamination will no longer differentiate between basic profile anddifference profile(s). In the identification the semantics describedabove in accordance with the table shown in FIG. 2 preferably should beused, but any other previously agreed semantics are also usably.

Possible alternative embodiment options for identifying a profile are asfollows:

1. The transmission profile is prefixed by a new header field in thecorresponding session layer (HTTP or WSP). The two Session Layerprotocols used here, HTTP and WSP (WSP: Wireless Session Protocol),allow in accordance with [8] and [9] the definition of new header fieldsand use the textual formats described in [10] when doing so, inaccordance with which a header field consists of a field name(mandatory) and a field value (optional). So that not too much data hasto be transmitted over the air interface WSP, [9] recommends binaryencoding for frequently used (“well-known”) header fields. Thus, forexample, from a field/attribute “X-Mms-Transmitter-Visibility: Show” (29Bytes) the short form “93 11” in hexadecimal encoding (two bytes) isproduced.

In accordance with a preferred embodiment of the present invention, theintroduction of new header fields is proposed for identification ofprofiles which also should be based on the format described in [10]. Thefield name of the new header field for the two profiles described hereHTTP and WSP could be called “x-wap-profile-source,” for example.

The presentation below shows the textually encoded header field“x-wap-profile-source” on the left with a textually encoded field valueon the right with a binary-encoded (decimal) field value:

x-wap-profile-source: WAP gateway; x-wap-profile-source: 2

2. The tagging is undertaken directly in the HTTP or WSP by anadditional parameter. As such, in principle, the same informationencoding as in the approach described under 1. is possible. To this end,for example, the definition of the header field “x-wap-profile” isexpanded by a parameter or allows the server-side assignment to a unitin the system.

3. The profile is expanded by a new XML attribute. As already explainedabove, all profiles are advantageously described for a WAP UA-Prof.basedon XML. Self-contained information blocks or individual information isdelimited within a profile by what are known as tags. Most of these tagsoccur in pairs in XML applications as start and end commands and specifythe meaning of the text enclosed within them. This text can, in itsturn, be subdivided by further tags, for example, to allow lists ofparameters for an attribute. The parameters of the individual tags arecalled attributes. They are always enclosed within quotation marks(“<”and “>”).

FIG. 3 shows the use of the newly defined XML attributes “Source”(highlighted in bold; entire new element enclosed by double arrows)which allow a profile (or an individual profile component) to beidentified by a terminal or by a transmission unit. When a new XMLattribute is used, the associated new XML “name space” must bereferenced in the corresponding profile, identified in this example by“prf2.” The value of this source attribute is encoded textually in FIG.3 (WAP GW or WAP Gateway). Also possible is a binary encoding of theattribute value in accordance with the table in FIG. 2 (e.g., “WAPGateway”=“2”).

If one also wishes to implement a consecutive numbering of profiles (asdescribed above) with the aid of XML attributes, the following twooptions are available for this purpose:

The attribute value of the attribute “Source” is defined in such a waythat it consists of a list of parameters with different meanings. FIG. 4shows an example of this in which the attribute value of “source”consists of a list of two parameters, with the bracketing mechanism ofattribute values described in the introduction being implemented. Withinthe attribute “source,” “Bag” signals that a number of attribute valuesfollow (in accordance with the present invention and new components areagain enclosed within two brackets). The expansion “Seq” in the bracketsrefers to the sequence of the parameters in the list being ofsignificance. By definition, parameter 1 for example could stand forconsecutive numbering and parameter 2 for the identification of theprofile by a terminal or a further component in the transmission path(e.g., a network unit), preferably by the code defined in the table inFIG. 2.

In addition to the textual encoding of UA-Profs or UA profiles shownhere, [7] also allows a binary method of representation in which alltextual attributes are assigned what are known as binary tokens.Naturally, the principles described above also could be expressed in abinary encoded UA-Prof.

A method described above for the transmission of user data objects usingattribute profiles or UA-Profs also may be applied for the transmissionof DRM-protected objects. If, in this case, in the embodiment of thetelecommunication arrangement described above or the profiletransmission and processing of the relevant components of atelecommunication arrangement of the WAP-capable terminal (T; cf.,FIG. 1) DRM-protected data is requested, the information flow is asillustrated below:

1. The WAP-capable terminal (T) sends a data request initially to theWAP gateway (G). This contains a basic profile BP* (let reference againbe made to FIG. 1 for the following explanations) and the differenceprofile DP3* for description of the add-on module. Both profiles areidentified by the new information described above to indicate that theycan be assigned to the WAP-capable terminal (T).

2. The WAP gateway (G) receives the data request and forwards it to thedata supply component (D). In doing so, it supplements the data requestby the difference profile DP2* which according to the new identificationcan be assigned to the WAP gateway.

3. The data supply component (D) receives the data request, evaluatesthe profile information and detects that the requested image can be usedby the terminal (T) itself in the “jpeg” format and that the WAP gateway(G) can convert images from “gif” format into a format suitable for theterminal (this only refers to “jpeg” here). If the object or the userdata object (the image) is now to be transmitted in DRM-protected form,it initially must be packed or encrypted into another data format (e.g.,“application/vnd.wap.drm.message or application/vnd.wap.drm.content”)which would make it inaccessible for the WAP gateway (G). The datasupply component (D) thus decides to pack the object in the “jpeg”format into the DRM format so that processing of the object by the WAPgateway is not necessary. The data supply component (D) sends the objector user data object to the WAP gateway in the format described.

4. The WAP gateway receives the object, detects that no processing ofthe object or an action by the WAP gateway (G) is necessary andtransmits it to the terminal (T).

5. The terminal receives the object, unpacks it and can use it.

Without the procedure described above in accordance with an embodimentof the present invention the same process would appear as follows:

1. The WAP-capable terminal (T) sends a data request initially to theWAP gateway (G). This contains the basic profile BP and the differenceprofile DP3 for description of the supplementary module (again, cf.,FIG. 1).

2. The WAP gateway (G) receives the data request and forwards it,supplemented by the difference profile DP2, to the data supply component(D).

3. The data supply component (D) receives the data request, evaluatesthe profile information and recognizes that the requested data or therequested image can be used by the combination of terminal (T) and WAPgateway (G) in “jpeg format” and in “gif format.” The object is to betransmitted in DRM-protected form and to this end must first be packedinto another data format (application/vnd.wap.drm.message orapplication/vnd.wap.drm.content) which makes it inaccessible to the WAPgateway. The data supply component of (D) may possibly decide to packthe object in the “gif” format into the DRM format, and send the objectto the WAP gateway (G) in the format described.

4. The WAP gateway (G) receives the object, recognizes that it cannotprocess the object since it does not recognize the data format enclosingit or cannot process this format, does not change the object andtransmits it to the terminal.

5. The terminal (T) receives the object, unpacks it from the enclosingdata format and, however, cannot use it.

Although the present invention has been described with reference tospecific embodiments, those of skill in the art will recognize thatchanges may be made thereto without departing from the spirit and scopeof the present invention as set forth in the hereafter appended claims.

Background information about the protocols discussed in the applicationmay be found in the following reference sources:

[1] 3GPP TS 23.040 version 5.2.0, Release 5; Third GenerationPartnership Project; Technical Specification Group Terminals; Technicalrealization of the Short Message Service (SMS).

[2] 3GPP TS 22.140 version 4.1.0, Release 4; Third GenerationPartnership Project; Technical Specification Group Services and SystemAspects; Service Aspects; Stage 1; Multimedia Messaging Service (MMS).

[3] 3GPP TS 23.140 version 5.1.0, Release 5; Third GenerationPartnership Project; Technical Specification Group Terminals; MultimediaMessaging Service (MMS); Functional Description; Stage 2.

[4] WAP-274-MMS Architecture Overview; WAP Multimedia Messaging Service(MMS) Specification Suite 2.0.

[5] WAP-275-MMS ClientTransaction; WAP Multimedia Messaging Service(MMS) Specification Suite 2.0.

[6] WAP-276-MMS Encapsulation; WAP Multimedia Messaging Service (MMS)Specification Suite 2.0.

[7] WAP-248-UAProf; WAG User Agent profile; October 2001.

[8] RFC 2616 “Hypertext Transfer Protocol—HTTP/1.1”; June 1999.

[9] WAP-230-WSP Wireless Session Protocol Specification, approvedversion 5 Jul. 2001.

[10] RFC 822 “Standard for the format of ARPA Internet text messages”;David H. Crocker; Aug. 13, 1982.

1-16. (canceled)
 17. A method for transmitting user data objects from adata supply component to a terminal of a user, via a connectioncomponent, the method comprising: providing a resulting profileinformation object which specifies which type of the user data objectsmay be transmitted to the terminal for processing; inserting, in theresulting profile information, a first item of profile information whichspecifies which type of the user data objects may be processed by theterminal; and transmitting the user data objects of the type inaccordance with the first profile information from the data supplycomponent to the terminal via the connection component.
 18. A method fortransmitting user data objects as claimed in claim 17, the methodfurther comprising inserting a second item of profile information intothe resulting profile information object which specifies which type ofthe user data objects may be converted by the connection component intothe type of user data objects which may be processed by the terminal.19. A method for transmitting user data objects as claimed in claim 18,further comprising transmitting the user data objects of the type inaccordance with the second profile information from the data supplycomponent to the terminal if no user data objects of the type inaccordance with the first profile information may be provided by thedata supply component.
 20. A method for transmitting user data objectsas claimed in claim 19, the method further comprising transmitting,before the transmission of the user data objects from the data supplycomponent to the terminal, a first sub-profile information object withthe first profile information to the connection component;supplementing, via the connection component, the first sub-profileinformation object by the second profile information to form a secondsub-profile information object; transmitting, via the connectioncomponent, the second sub-profile information object to the data supplycomponent; and creating the resulting profile information object basedon all transmitted profile information at the data supply component. 21.A method for transmitting user data objects as claimed in claim 20,further comprising supplementing the terminal with an additional servicecomponent which may expand a scope of the user data objects able to beprocessed by the terminal.
 22. A method for transmitting user dataobjects as claimed in claim 21, further comprising expanding the firstsub-profile information object by a third item of profile informationwhich specifies the types of the user data objects by which the scope ofthe user data objects of the terminal is expanded by the additionalservice component.
 23. A method for transmitting user data objects asclaimed in claim 20, wherein, in at least one of the first and secondsub-profile information objects, the profile information is provided inreference form which refers in each case to profile information which isstored on one of the data supply component and a further data supplycomponent connected thereto.
 24. A method for transmitting user dataobjects as claimed in claim 17, wherein the terminal is located in afirst telecommunication network and at least one of the data supplycomponent and a further data supply component connected thereto arelocated in a second telecommunication network, with the first and secondtelecommunication networks being connected to each other.
 25. A methodfor transmitting user data objects as claimed in claim 24, wherein theconnection component is arranged in one of the first and secondtelecommunication networks or is intended to connect the first andsecond telecommunication networks together.
 26. A method fortransmitting user data objects as claimed in claim 24, wherein the firsttelecommunication network is a mobile radio network which is operated inaccordance with at least one of a GSM standard and a UMTS standard. 27.A method for transmitting user data objects as claimed in claim 26,wherein the user data objects are transmitted to the terminal in thefirst telecommunication network via a Wireless Session Protocol.
 28. Amethod for transmitting user data objects as claimed in claim 24,wherein the second telecommunication network is a network based on anInternet protocol in which data is transmitted via a Hypertext TransferProtocol.
 29. A method for transmitting user data objects as claimed inclaim 17, wherein the terminal includes a radio module.
 30. A method fortransmitting user data objects as claimed in claim 29, wherein theterminal is one of a mobile telephone, a cordless telephone, a portablecomputer and a smartphone.
 31. A method for transmitting user dataobjects as claimed in claim 17, wherein the connection component is aWAP gateway.
 32. A method for transmitting user data objects as claimedin claim 17, wherein the user data objects include at least one of textinformation, audio information, video information, executable programsand software modules.
 33. A system for transmitting user data objects,comprising: a data supply component; a connection component; and aterminal of a user; wherein a resulting profile information objectspecifies which type of the user data objects may be transmitted to theterminal for processing; wherein a first item of profile information isinserted in the resulting profile information which specifies which typeof user data objects may be processed by the terminal; and wherein theuser data objects of the type in accordance with the first profileinformation are transmitted from the data supply component to theterminal via the connection component.